Skip to content

Add missing zephyr,memory-region in STM32 dts & use LINKER_DT_NODE_REGION_NAME in LTDC for ext-sdram #95299

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Add missing zephyr,memory-region in STM32 dts & use LINKER_DT_NODE_REGION_NAME in LTDC for ext-sdram #95299

wants to merge 3 commits into from

Conversation

avolmat-st
Copy link

This PR first goal is to introduce usage of the LINKER_DT_NODE_REGION_NAME within the STM32 LTDC driver in order to benefit from the Zephyr linker script generated based on zephyr,memory-region. With that done it is no more necessary to rely on STM32 specific linker scripts to select the area to store the framebuffer and simply point to the node of that memory using the ext-sdram property of the LTDC.
(btw, might want to change that property name, since this is not only SDRAM however maybe another PR, including migration-guide update might be better for that ...).

For this to work, regions to hold that framebuffer must have the right compatible in order to have Zephyr generate the linker-script properly. Looking within stm32 dtsi/dts files, I noticed that some were missing, especially for the STM32L4 for which I targetted that in the first place.

The first commit is thus adding the missing zephy,memory-region compatibles. While some are really necessary, I have doubt regarding some others. Since over the zephyr,sram is also pointing to such memory area, this leads also to cases where there is two lines printed in the print-memory-usage at the end of the build, such as below:

Memory region         Used Size  Region Size  %age Used
           FLASH:       45672 B         2 MB      2.18%
             RAM:       25088 B       192 KB     12.76%
           SRAM0:          0 GB       192 KB      0.00%
           SRAM1:          0 GB        64 KB      0.00%
           SRAM2:      304200 B       384 KB     77.36%
        IDT_LIST:          0 GB        32 KB      0.00%

Above, the RAM and SRAM0 are actually the same region. Adding the zephyr,memory-region to SRAM0 makes it appears in the memory usage summary, and wrongly mentioned as usage is 0 while it is actually also RAM, hence 12.76% in the case above.
At the same time, the choice of having zephyr,sram pointing to the sram0 can vary (not always though) from a board / variant to another so it sounds like a good thing to have sram0 described as compatible zephyr,memory-region from within the .dtsi.
So, here a discussion point.

In a second commit, LTDC driver is updated to rely on the LINKER_DT_NODE_REGION_NAME macro to figure out the attribute to where store the framebuffer instead of STM32 specific hardcoded region names.

My understanding is that memc stm32 specific linker scripts were added for this purpose, so since LTDC do not need them anymore I removed them. If there were another usage for those linker scripts, then 3rd commit might not be needed.

@avolmat-st avolmat-st force-pushed the pr-stm32-memory-region-ltdc branch from 000573c to 6ad4729 Compare September 1, 2025 19:45
@avolmat-st avolmat-st mentioned this pull request Sep 1, 2025
Open
@avolmat-st avolmat-st requested a review from erwango September 1, 2025 19:49
@avolmat-st avolmat-st marked this pull request as ready for review September 2, 2025 18:54
@JarmouniA JarmouniA mentioned this pull request Sep 9, 2025
Open
gautierg-st
gautierg-st reviewed Sep 11, 2025
View reviewed changes
Copy link
Contributor

@gautierg-st gautierg-st left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only potentially blocking point is indeed the wrong information concerning the occupancy of the SRAM. I don't know what tool is responsible for this summary, nor how it works, but it's a bit strange that it does not detect that it is the same RAM, and unless there is a way to write the device tree to avoid this, I'd say the problem lies on this tool.

Removing the labels and the compatibles specifically for these SRAMs just to avoid this prompt doesn't seem like a good solution since the SRAM selected as zephyr,sram could be changed to another that has the label, and thus the problem would reappear.

I also agree that renaming the ext-sdram property would be good but should be done in an ulterior PR.

@avolmat-st
Copy link
Author

The message is actually coming from the linker of the toolchain and is displayed when the following Zephyr option is set:

config OUTPUT_PRINT_MEMORY_USAGE
        bool "Print memory usage to stdout"
        default y
        help
          If the toolchain supports it, this option will pass
          --print-memory-region to the linker when it is doing it's first
          linker pass. Note that the memory regions are symbolic concepts
          defined by the linker scripts and do not necessarily map
          directly to the real physical address space. Take also note that
          some platforms do two passes of the linker so the results do not
          match exactly to the final elf file. See also rom_report,
          ram_report and
          https://sourceware.org/binutils/docs/ld/MEMORY.html

nashif
nashif previously approved these changes Sep 13, 2025
View reviewed changes
@nashif
Copy link
Member

nashif commented Sep 13, 2025

needs rebase :)

@avolmat-st avolmat-st force-pushed the pr-stm32-memory-region-ltdc branch from 6ad4729 to 651bd1b Compare September 13, 2025 16:07
@avolmat-st
Copy link
Author

Found an issue on the stm32l4r5.dtsi. Since the sram2 base is not the same as on stm32l4p5.dtsi, the memory-region naming was lost. Adding this in this intermediate push to make it visible to reviewers.

Alain Volmat added 3 commits September 13, 2025 18:09
dts: arm: st: add zephyr,memory-region on all missing stm32 dts
e96e9ba 
Add the compatible zephyr,memory-region for all mmio-sram region
which do not have yet that compatible as well as add the label to
those regions. This allow to have a linker memory report which list
all areas and also have all regions accessible via the linker script.

Signed-off-by: Alain Volmat <[email protected]>
display: stm32_ltdc: use LINKER_DT_NODE_REGION_NAME for ext-sdram
ffdda37 
Use the LINKER_DT_NODE_REGION_NAME macro in order to get the
memory-region into which to put the framebuffer for the LTDC.
This is made possible since all memory areas have the
zephyr,memory-region compatible, allowing to have each region
referenced within the linker script generated by Zephyr.

Signed-off-by: Alain Volmat <[email protected]>
drivers: memc: stm32: removal of sdram1/sdram2/psram sections handling
6f32b56 
SDRAM1 / SDRAM2 / PSRAM sections were being referenced in order to make
them accessible for the framebuffer. This is now addressed via the
mechanism provided by Zephyr hence this is no more necessary.

Signed-off-by: Alain Volmat <[email protected]>
@avolmat-st avolmat-st force-pushed the pr-stm32-memory-region-ltdc branch from 651bd1b to 6f32b56 Compare September 13, 2025 16:11
@avolmat-st
Copy link
Author

Simply rebased on top of main, with correction of the conflict in mp13.dtsi due to recent dtslint run on those files.

@sonarqubecloud SonarQubeCloud
Copy link

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@erwango
Copy link
Member

erwango commented Sep 18, 2025

The message is actually coming from the linker of the toolchain and is displayed when the following Zephyr option is set:

And btw, the linker MEMORY section it parses is filled through the usage of LINKER_DT_REGIONS() DT macro.
One idea would be to skip the insertion of the region is size and start address match the ones of the RAM region, but using DT macros this feels tedious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gautierg-st gautierg-st gautierg-st left review comments

@nashif nashif nashif left review comments

@erwango erwango Awaiting requested review from erwango

@danieldegrasse danieldegrasse Awaiting requested review from danieldegrasse

@djiatsaf-st djiatsaf-st Awaiting requested review from djiatsaf-st

@etienne-lms etienne-lms Awaiting requested review from etienne-lms

@FRASTM FRASTM Awaiting requested review from FRASTM

@GeorgeCGV GeorgeCGV Awaiting requested review from GeorgeCGV

@JarmouniA JarmouniA Awaiting requested review from JarmouniA

@jfischer-no jfischer-no Awaiting requested review from jfischer-no

@marwaiehm-st marwaiehm-st Awaiting requested review from marwaiehm-st

@mathieuchopstm mathieuchopstm Awaiting requested review from mathieuchopstm

@VynDragon VynDragon Awaiting requested review from VynDragon

At least 2 approving reviews are required to merge this pull request.

Assignees

@nashif nashif

@erwango erwango

Labels
area: Display area: Linker Scripts area: MEMC platform: STM32 ST Micro STM32
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@avolmat-st @nashif @erwango @gautierg-st @zephyrbot